home *** CD-ROM | disk | FTP | other *** search
/ PC World Komputer 2003 November A / PCWK1103A.iso / Adobe After Effects 6.0 tryout / MM4.Cab / F3615_README.TXT.942461E0_7FE8_440B_86B6_AA6592C2EC51 < prev    next >
Text File  |  2003-03-20  |  27KB  |  551 lines
  1. ##Adobe File Version: 1.000
  2. #=======================================================================
  3. #   FTP file name:  README.TXT
  4. #
  5. #   Contents:       Background information on Unicode mapping tables
  6. #                   for Mac OS text encodings
  7. #
  8. #   Copyright:      (c) 1995-1999 by Apple Computer, Inc., all rights
  9. #                   reserved.
  10. #
  11. #   Contact:        charsets@apple.com
  12. #
  13. #   Changes:
  14. #
  15. #       b02  1999-Sep-22    Update information on Cyrillic. Update
  16. #                           contact e-mail address.
  17. #       n07  1998-Feb-05    Rewrite to provide additional information
  18. #                           relevant to using the accompanying mapping
  19. #                           tables, and to delete some extraneous
  20. #                           information. Delete Bulgarian (no special
  21. #                           encoding, uses standard Cyrillic), add
  22. #                           Farsi, Devanagari, Gurmukhi, Gujarati,
  23. #                           Celtic, Gaelic, Inuit, Tibetan.
  24. #       n04  1995-Nov-15    Update info for Hebrew and Thai
  25. #       n03  1995-Apr-15    First version (after fixing some typos).
  26. #
  27. ##################
  28.  
  29. 0. Preliminaries
  30. ----------------
  31.  
  32. For maximum interchangeability, this file and the accompanying Mac OS 
  33. mapping tables use only ASCII characters. They are intended to be 
  34. displayed in a monospaced font.
  35.  
  36. Apple, the Apple logo, Mac, and Macintosh are trademarks of Apple 
  37. Computer, Inc., registered in the United States and other countries. 
  38. QuickDraw and TrueType are trademarks of Apple Computer, Inc. Unicode is 
  39. a trademark of Unicode Inc. PostScript is a trademark of Adobe Systems 
  40. Inc., which may be registered in certain jurisdictions. IBM is a 
  41. registered trademark of International Business Machines Corporation. ITC 
  42. Zapf Dingbats is a registered trademark of the International Typeface 
  43. Corporation. For the sake of brevity, throughout this document and the 
  44. accompanying tables, "Macintosh" can be used to refer to Macintosh
  45. computers and "Unicode" can be used to refer to the Unicode standard.
  46.  
  47. Apple Computer, Inc. ("Apple") makes no warranty or representation, 
  48. either express or implied, with respect to this document and the 
  49. accompanying tables, their quality, accuracy, or fitness for a 
  50. particular purpose. In no event will Apple be liable for direct, 
  51. indirect, special, incidental, or consequential damages resulting from 
  52. any defect or inaccuracy in this document or the accompanying tables.
  53.  
  54. 1. Introduction
  55. ---------------
  56.  
  57. This document summarizes some Unicode mapping considerations that are
  58. relevant for the accompanying mapping tables. It also provides an
  59. overview of Mac OS encodings.
  60.  
  61. These mapping tables and character lists are subject to change.
  62. The latest tables should be available from the following:
  63.  
  64. <ftp://ftp.unicode.org/Public/MAPPINGS/VENDORS/APPLE/>
  65. <ftp://dev.apple.com/devworld/Technical_Documentation/Misc._Standards/>
  66.  
  67. 2. Round-trip fidelity and overview of mapping techniques
  68. ---------------------------------------------------------
  69.  
  70. For a particular set of national and international standards, Unicode
  71. provides round-trip fidelity: Text in one of those encodings can be
  72. mapped to Unicode and back again, yielding the original characters.
  73. Characters which are distinct in one of these source standards have 
  74. a distinct counterpart in Unicode. Note that this counterpart might not
  75. be a single Unicode character; as is pointed out in "The Unicode
  76. Standard, Version 2.0" (page 2-10), "sometimes a single code value in
  77. another standard corresponds to a sequence of code values in the Unicode
  78. Standard, or vice versa."
  79.  
  80. However, Unicode does not attempt to provide round-trip fidelity for 
  81. most vendor standards. Nevertheless, Apple and other platform vendors 
  82. may need to provide such round-trip fidelity for their current encodings 
  83. (this can be important in file systems, for example). In order to do 
  84. this, Apple makes use of some Unicode characters in the corporate-use
  85. zone (the upper end of the private use area).
  86.  
  87. Corporate-zone characters must be used with care. Indiscriminate use of
  88. such characters can result in text which is not easily interchanged with
  89. other systems, since these characters have no standard meaning outside a
  90. particular platform. The mappings provided here are intended to minimize
  91. the use of private use characters, or to use them in such a way that
  92. basic text content will not be lost if the corporate zone characters are
  93. dropped when text is transferred to another system.
  94.  
  95. The tables provided here have three goals, in the following order of
  96. importance:
  97. 1. Provide 100% round-trip mapping from a Mac OS encoding to Unicode
  98. and back (even if the mappings here are converted to maximal
  99. decompositions, see below).
  100. 2. Map characters in a Mac OS encoding into the Unicode characters
  101. that best represent the interpretation and usage of the Mac OS
  102. characters.
  103. 3. When mapping text in a Mac OS encoding to Unicode using the tables,
  104. the resulting Unicode text should be as interchangeable as possible.
  105.  
  106. To satisfy these goals, the mappings use a variety of techniques. First
  107. we attempt to achieve round-trip mappings using any standard Unicode
  108. feature at our disposal, without resorting to corporate-zone characters.
  109. This can includes the following techniques:
  110. - Use of all Unicode characters defined in Unicode 2.1, including
  111.   compatibility characters.
  112. - Mapping a single character in a Mac OS encoding to a sequence of
  113.   standard Unicode characters, or vice versa. This requires grouping
  114.   characters into appropriate chunks for lookup before mapping them
  115.   (this mainly applies to sequences of Unicode characters).
  116. - Using Unicode direction overrides to force direction attributes when
  117.   mapping to Unicode. This requires resolution of Unicode character
  118.   direction, and use of this information, when mapping from Unicode back
  119.   to certain Mac OS encodings.
  120. The requirements imposed on Unicode handling are necessary for other,
  121. non-transcoding operations in a full Unicode implementation anyway, so
  122. requiring them for transcoding should not impose much of a burden.
  123.  
  124. Next, if round-trip fidelity cannot be achieved using the above
  125. techniques, we attempt to use corporate-zone characters only as
  126. "transcoding hints" (more on this below). These are combined with one or
  127. more standard Unicode characters to mark them as special for
  128. transcoding, but have no other function and can be deleted with no loss
  129. of basic text content (only of round-trip fidelity).
  130.  
  131. Finally, if a character in a Mac OS encoding is unrelated to any Unicode
  132. or Unicode sequence, we may map it to a single corporate-zone Unicode
  133. code point.
  134.  
  135. These techniques are described in more detail in the following sections.
  136.  
  137. Some clients of these tables may have a different set of goals. For
  138. example, some clients may prefer to avoid compatibility characters,
  139. perhaps sacrificing round-trip fidelity if necessary. In most cases it
  140. is fairly easy to construct other types of mappings from the mappings
  141. given here. In particular, the mappings here have been designed so that
  142. if they are converted to maximal decomposition mappings (by recursive
  143. application of the canonical decompositions in the Unicode database),
  144. the resulting mappings will still provide 100% roundtrip fidelity.
  145.  
  146. There is one more round-trip issue that should be mentioned. If a
  147. Unicode character or sequence can be mapped at all into a particular
  148. Mac encoding, then the reverse mapping back to Unicode should yield
  149. the original Unicode character or sequence (except for possible 
  150. differences in direction overrides or other Unicode characters in the
  151. "Other, Format" category). The tables here also provide this. For a
  152. related issue, see the next section.
  153.  
  154. 3. Mapping tolerance: Strict and loose
  155. --------------------------------------
  156.  
  157. In many character sets, a single character may have multiple semantics, 
  158. either by explicit definition, ambiguous definition, or established 
  159. usage. For example, the JIS character 0x2142, or 0x8161 in Shift-JIS, 
  160. is specified in the JIS X0208 standard to have two meanings: "double 
  161. vertical line" and "parallel". Each of these meanings corresponds to a 
  162. different Unicode character: 0x2016 DOUBLE VERTICAL LINE and 0x2225 
  163. PARALLEL TO. When mapping from Unicode to Shift-JIS, it is normally 
  164. desirable to map both of these Unicode characters to the single
  165. Shift-JIS character. However, when mapping the Shift-JIS character to
  166. Unicode, we can choose only one of the possible Unicode characters.
  167.  
  168. For two encodings X and Y, we can define a set of "strict" mappings
  169. from one to the other as follows: If text in X can be mapped to Y using
  170. the strict mappings from X to Y, then the resulting text can be mapped
  171. back using the strict mappings from Y to X to end up with the original
  172. text from X. Similarly, if text in Y can be mapped to X using the strict
  173. mappings from Y to X, then the resulting text can be mapped back using
  174. the strict mappings from X to Y to end up with the original text from Y.
  175.  
  176. There may be several characters in one encoding that all map to a
  177. single character in another encoding, but only one of these mappings
  178. can be strict; the others are "loose".
  179.  
  180. The mappings given in the accompanying tables are strict mappings.
  181. However, the Mac OS Text Encoding Converter also supports loose
  182. mappings and fallback mappings. Some of the accompanying tables provide
  183. suggestions about possible loose mappings.
  184.  
  185. 4. Mapping a Mac encoding character to a Unicode sequence or vice versa
  186. -----------------------------------------------------------------------
  187.  
  188. In some cases, a character in a Mac OS encoding maps to a sequence of
  189. Unicode characters. For example, the Mac OS Japanese encoding includes
  190. a character for the circled CJK ideograph "big". Although Unicode
  191. encodes other circled ideographs as single characters, it does not
  192. encode this one. However, this character can be unambiguously
  193. represented in Unicode as the Unicode sequence 0x5927+0x20DD, the CJK 
  194. ideograph for "big" followed by COMBINING ENCLOSING CIRCLE.
  195.  
  196. To handle the reverse mapping, a transcoding process must group the
  197. Unicode sequence 0x5927+0x20DD as a single element for lookup (The
  198. Mac OS Text Encoding Converter does this).
  199.  
  200. In a few cases, a sequence of characters in a Mac OS encoding must
  201. be grouped for mapping to a single Unicode character or a sequence
  202. of Unicode characters. For example, in Mac OS Devanagari (based on
  203. ISCII-91), DEVANAGARI LETTER VOCALIC L is represented as 0xA6+0xE9;
  204. but this is represented in Unicode by the single character 0x090C.
  205. Furthermore, explicit halant is represented in Mac OS Devanagari as
  206. 0xE8+0xE8 (double halant) and in Unicode as 0x094D+0x200C (VIRAMA
  207. plus ZERO WIDTH NON-JOINER). The latter can also be considered as
  208. a context-dependent mapping of 0xE8, halant.
  209.  
  210. Loose mappings from Unicode to a Mac OS encoding often map a single
  211. Unicode to a sequence of characters in the Mac OS encoding. For example,
  212. the Unicode character 0x00BD VULGAR FRACTION ONE HALF cannot be mapped
  213. into the Mac OS Roman character set as a single character, but it has a
  214. loose mapping to the sequence 0x31+0xDA+0x32, "digit one" + "fraction
  215. slash" + "digit two".
  216.  
  217. In some cases a Unicode character such as a direction override may
  218. simply be discarded when mapping to a Mac OS encoding, since the
  219. information carried by the override may be represented in a different
  220. way by the Mac OS encoding. See the next section for an example.
  221.  
  222. 5. Mappings that depend on directionality (or other attributes)
  223. ---------------------------------------------------------------
  224.  
  225. Strict mappings from Unicode to Mac OS encodings may depend on resolved
  226. character direction. Loose mappings may depend on additional attributes
  227. such as the state of symmetric swapping and whether the text should use
  228. vertical form codes if available (i.e. whether the text is intended for
  229. vertical display on a system that cannot automatically substitute
  230. vertical forms).
  231.  
  232. a) Resolved character direction
  233.  
  234. The Mac OS Arabic and Hebrew character sets were developed in 1986-1987.
  235. At that time the bidirectional line layout algorithm used in the Mac OS
  236. was fairly simple; it used only a few direction classes (instead of the
  237. 13 or so now used in the Unicode bidirectional algorithm). In order to
  238. permit users to handle some tricky layout problems, certain punctuation
  239. and symbol characters have duplicate code points, one with a left-right 
  240. direction attribute and the other with a right-left direction attribute.
  241.  
  242. For example, plus sign is encoded at 0x2B with a left-right attribute,
  243. and at 0xAB with a right-left attribute. However, there is only one PLUS
  244. SIGN character in Unicode. This leads to some interesting problems when
  245. mapping between Mac OS Arabic or Hebrew and Unicode.
  246.  
  247. We need a way to map both of these plus signs to Unicode and back. Using
  248. a single corporate character for one of these plus signs is not a good
  249. solution, since both of the plus sign characters are likely to be used
  250. in text that is interchanged, and thus content would be lost.
  251.  
  252. The problem is solved with the use of direction override characters and
  253. direction-dependent mappings. When mapping from Mac OS Arabic or Hebrew
  254. to Unicode, we use direction overrides as necessary to force the
  255. direction of the resulting Unicode characters. When mapping back from
  256. Unicode, the Unicode bidirectional algorithm should be used to determine
  257. resolved direction of the Unicode characters. The mapping from Unicode
  258. to Mac OS Arabic or Hebrew can then be disambiguated as necessary by
  259. using the resolved direction.
  260.  
  261. For example, when mapping from Mac OS Arabic or Hebrew, we can use
  262. LEFT-RIGHT OVERRIDE (LRO), RIGHT-LEFT OVERRIDE (RLO), and POP DIRECTION
  263. FORMATTING (PDF) as follows:
  264.  
  265.   0x2B ->  0x202D (LRO) + 0x002B (PLUS SIGN) + 0x202C (PDF)
  266.   0xAB ->  0x202E (RLO) + 0x002B (PLUS SIGN) + 0x202C (PDF)
  267.  
  268. When mapping back, we resolve the direction of the Unicode character
  269. 0x002B, and use this information to determine which of the Mac OS
  270. encoding characters to use:
  271.  
  272.   0x002B -> 0x2B (if LR) or 0xAB (if RL)
  273.   
  274. After direction overrides have been used in this way to force a
  275. particular resolved direction, they may be discarded when mapping from
  276. Unicode to Mac OS Arabic and Hebrew (since the information they carried
  277. in Unicode is represented in the Mac OS encoding by the code point of
  278. the plus sign).
  279.  
  280. Even when not required for round-trip fidelity, direction overrides
  281. may be used when mapping from a Mac OS encoding to Unicode in order to
  282. preserve proper text layout. For example, the single Mac OS Arabic
  283. ellipsis character has direction class right-left, while the Unicode
  284. HORIZONTAL ELLIPSIS character has direction class neutral. When 
  285. mapping the Mac OS ellipsis to Unicode, it is surrounded with a
  286. direction override to help preserve proper text layout. However,
  287. resolved direction is not needed or used when mapping the Unicode
  288. HORIZONTAL ELLIPSIS back to Mac OS Arabic.
  289.  
  290. b) Symmetric swapping
  291.  
  292. In loose mappings from Unicode to the Mac OS Arabic character set, the 
  293. state of symmetric swapping (which may be changed by the Unicode 
  294. characters 0x206A, 0x206B) affects the mapping of paired characters such 
  295. as punctuation and brackets. This does not affect the strict mappings 
  296. given in the accompanying tables.
  297.  
  298. c) Horizontal or vertical display
  299.  
  300. The Mac OS Japanese encoding includes separately-encoded vertical forms
  301. for some punctuation and kana. When Unicode characters in the CJK
  302. punctuation and kana ranges are mapped to Mac OS Japanese characters and
  303. (1) those characters are intended for vertical display, (2) they will be
  304. displayed in an environment that does not provide automatic vertical
  305. form substitution, and (3) loose mappings are desired, the Unicode
  306. characters can be mapped to the corresponding vertical form codes in the
  307. Mac OS Japanese encoding.
  308.  
  309. This does not affect mapping of the Unicode vertical presentation forms
  310. (which always map to the Mac OS Japanese vertical form codes).
  311.  
  312. 6. Use of corporate characters
  313. ------------------------------
  314.  
  315. Apple has defined a block of 32 corporate characters as "transcoding
  316. hints." These are used in combination with standard Unicode characters
  317. to force them to be treated in a special way for mapping to other
  318. encodings; they have no other effect. Sixteen of these transcoding
  319. hints are "grouping hints" - they indicate that the next 2-4 Unicode
  320. characters should be treated as a single entity for transcoding. The
  321. other sixteen transcoding hints are "variant tags" - they are like
  322. combining characters, and can follow a standard Unicode (or a sequence
  323. consisting of a base character and other combining characters) to
  324. cause it to be treated in a special way for transcoding. These always
  325. terminate a combining-character sequence.
  326.  
  327. Whenever possible, mappings that require corporate-zone characters
  328. use standard Unicode characters in combination with a single
  329. transcoding hint (no mapping uses more than one transcoding hint).
  330. For these mappings, even if the corporate-zone characters are lost in
  331. interchange, the basic text content will be preserved.
  332.  
  333. However, some characters in a Mac OS encoding - such as the Apple
  334. logo character - bear no relation to any standard Unicode character.
  335. In these cases, the Mac OS character is mapped to a single corporate
  336. zone character defined by Apple. Fewer than 15 corporate characters
  337. are used in this way.
  338.  
  339. All of the corporate characters defined by Apple are listed in the
  340. accompanying file "CORPCHAR.TXT", including old Apple corporate
  341. character assignments which are now deprecated (but which are still
  342. supported as loose mappings by the Mac OS Text Encoding Converter).
  343.  
  344. 7. Font variants
  345. ----------------
  346.  
  347. For some Mac OS encodings, certain fonts used with that encoding may
  348. actually implement a slight variant of the standard encoding specified
  349. in the accompanying mapping tables. The header comments in the mapping
  350. table files for each encoding describe any font variants associated with
  351. that encoding.
  352.  
  353. 8. Mac OS encodings
  354. -------------------
  355.  
  356. The Mac OS can support multiple encodings. In the current Mac OS  
  357. architecture these encodings are distinguished primarily by script code:
  358. font family IDs are grouped into ranges, and each range is associated
  359. with a script code. 
  360.  
  361. In some cases, there are several encodings that share a single script
  362. code. Usually these are closely related. To distinguish among these,
  363. additional information is required, such as font name or system
  364. region code (locale code).
  365.  
  366. The encodings described here (and in the accompanying tables) are the 
  367. encodings used in Mac OS versions 7.1 and later. In some cases, certain 
  368. earlier system versions have used different encodings.
  369.  
  370. In all Mac OS encodings, character codes 0x00-0x7F are identical to
  371. ASCII, except that
  372.   - in Mac OS Japanese, reverse solidus is replaced by yen sign
  373.   - in Mac OS Arabic, Farsi, and Hebrew, some of the punctuation in this
  374.     range is treated as having strong left-right directionality,
  375.     although the corresponding Unicode characters have neutral
  376.     directionality
  377. Fonts used as "system" fonts (for menus, dialogs, etc.) have four glyphs
  378. at code points 0x11-0x14 for transient use by the Menu Manager. These
  379. glyphs are not intended as characters for use in normal text, and the
  380. associated code points are not generally interpreted as associated with
  381. these glyphs. (However, a "system font variant" mapping table could
  382. provide mappings for these).
  383.  
  384. Note that in general, character sets cannot be determined from font 
  385. layouts (they are not the same thing!). This is very noticeable with 
  386. Arabic, Hebrew, and Devanagari, for example.
  387.  
  388. The following is a list of current Mac OS encodings. The accompanying
  389. tables provide mappings from these encodings to Unicode 2.1.
  390.  
  391. a) Mac OS encodings for script code 0, smRoman.
  392.  
  393. * Roman - this is the default for script code 0 (when the special
  394.   cases listed below do not apply). It covers several western European
  395.   languages, and includes math operators and various symbols.
  396.  
  397. * Symbol - this is the encoding for the font named "Symbol". It includes
  398.   Greek letters, math operators, and miscellaneous symbols. The layout
  399.   of the Symbol character set is identical to the layout of the Adobe
  400.   Symbol encoding vector, with the addition of the Apple logo at 0xF0
  401.   and the EURO SIGN at 0xA0.
  402.  
  403. * Dingbats - this is the encoding for the font named "Zapf Dingbats".
  404.   The layout of the Dingbats character set is identical to or a superset
  405.   of the layout of the Adobe Zapf Dingbats encoding vector.
  406.  
  407. * Turkish - this is the encoding if the script code is 0 and the system
  408.   region code is 24, verTurkey. It has 7 code point differences from
  409.   Mac OS Roman.
  410.  
  411. * Croatian - this is the encoding if the script code is 0 and the system
  412.   region code is any of the following:
  413.     68, verCroatia
  414.     66, verSlovenian
  415.     25, verYugoCroatian (only used in older systems)
  416.   It has 20 code point differences from standard Roman, but only 10
  417.   differences in repertoire.
  418.  
  419. * Icelandic - this is the encoding if the script code is 0 and the
  420.   system region code is either of the following:
  421.     21, verIceland
  422.     47, verFaroeIsl
  423.   It has 6 code point differences from standard Roman. It also has one
  424.   font variant.
  425.  
  426. * Romanian - this is the encoding if the script code is 0 and the system
  427.   region code is 39, verRomania . It has 6 code point differences from
  428.   standard Roman.
  429.  
  430. * Celtic - this is the encoding if the script code is 0 and the system
  431.   region code is any of the following:
  432.     50, verIreland
  433.     75, verScottishGaelic
  434.     76, verManxGaelic
  435.     77, verBreton
  436.     79, verWelsh
  437.   It is a variant of Mac OS Roman with a few extra accented characters
  438.   for Welsh.
  439.  
  440. * Gaelic - this is the encoding if the script code is 0 and the system
  441.   region code is 81, verIrishGaelicScript. It is a variant of Mac OS
  442.   Roman, and supports the older Irish orthography using dot above.
  443.  
  444. * Greek (monotonic) - this is the encoding if the script code is 0 and
  445.   the system region code is 20, verGreece. Although a script code is
  446.   defined for Greek, the Greek localized system does not use it (the
  447.   font family IDs are in the smRoman range). This encoding is based on
  448.   the ISO/IEC 8859-7 repertoire with additional Roman characters for
  449.   French and German, as well as additional symbols. Greek system 4.1
  450.   used a different encoding that matched 8859-7 code points for Greek
  451.   letters. Greek system 6.0.7 also used a variant of the standard
  452.   encoding, but it was quickly replaced by Greek system 6.0.7.1 which
  453.   used the standard encoding.
  454.  
  455.   See also the Central European encoding under script code 29 below.
  456.  
  457. b) Mac OS encodings for script code 1, smJapanese.
  458.  
  459. * Japanese - this is the default for script code 1. It is based on a
  460.   Shift-JIS implementation of JIS X0208-1990 ("fullwidth") and
  461.   JIS X0201-1976 ("halfwidth"), with 5 additional one-byte characters
  462.   and one modified character, a set of Apple extension characters which
  463.   include many industry standard extensions, and separate codes for
  464.   vertical forms of some punctuation and kana. There are several font
  465.   variants.
  466.  
  467. c) Mac OS encodings for script code 2, smTradChinese.
  468.  
  469. * Chinese Traditional - this is an extension of Big-5.
  470.  
  471. d) Mac OS encodings for script code 3, smKorean.
  472.  
  473. * Korean - this is an extension of EUC-KR.
  474.  
  475. e) Mac OS encodings for script code 4, smArabic.
  476.  
  477. * Arabic - This is the default for script code 4 (when the special
  478.   case listed below does not apply). It is based on the ISO/IEC 8859-6
  479.   repertoire, with additional Arabic letters for Persian and Urdu and
  480.   with accented Roman letters for European languages. It has the
  481.   interesting feature mentioned above that certain ASCII punctuation
  482.   and symbol characters are encoded twice, once for each direction. It
  483.   has several font variants.
  484.  
  485. * Farsi - This is the encoding if the script code is 4 and the system
  486.   region code is 48, verIran. It is similar to Mac OS Arabic, but has
  487.   the "extended" or Persian digits instead of the standard Arabic
  488.   digits. It has one font variant.
  489.  
  490. f) Mac OS encodings for script code 5, smHebrew.
  491.  
  492. * Hebrew - This is based on the ISO/IEC 8859-8 Hebrew letter repertoire,
  493.   but adds Hebrew points, some Hebrew ligatures, some accented Roman
  494.   letters for European languages, and some non-ASCII punctuation. As 
  495.   with Mac OS Arabic, certain ASCII punctuation and symbol characters
  496.   are encoded twice, once for each direction. This is also true for the
  497.   European digits. This has one font variant.
  498.  
  499. g) Mac OS encodings for script code 6, smGreek.
  500.  
  501.   None currently - see smRoman.
  502.  
  503. h) Mac OS encodings for script code 7, smCyrillic.
  504.  
  505. * Cyrillic - This is based on the ISO/IEC 8859-5 Cyrillic character
  506.   repertoire plus an additional case pair for Ukrainian.
  507.  
  508. i) Mac OS encodings for script code 9, smDevanagari.
  509.  
  510. * Devanagari - This is based on IS 13194:1991 (ISCII-91), and adds some
  511.   punctuation and symbols.
  512.  
  513. j) Mac OS encodings for script code 10, smGurmukhi.
  514.  
  515. * Gurmukhi - This is based on IS 13194:1991 (ISCII-91), and adds some
  516.   punctuation and symbols.
  517.  
  518. k) Mac OS encodings for script code 11, smGujarati.
  519.  
  520. * Gujarati - This is based on IS 13194:1991 (ISCII-91), and adds some
  521.   punctuation and symbols.
  522.  
  523. l) Mac OS encodings for script code 21, smThai.
  524.  
  525. * Thai - This is based on TIS 620-2533, except that three of the
  526.   TIS 620-2533 characters are replaced with other characters. Some
  527.   undefined code points in TIS 620-2533 are used for additional
  528.   punctuation characters.
  529.  
  530. m) Mac OS encodings for script code 25, smSimpChinese.
  531.  
  532. * Chinese Simplified - this is an extension of EUC-CN.
  533.  
  534. n) Mac OS encodings for script code 26, smTibetan.
  535.  
  536. * Tibetan
  537.  
  538. o) Mac OS encodings for script code 28, smEthiopic.
  539.  
  540. * Inuit - this is the encoding if the script code is 28 and the
  541.   system region code is 78, verNunavut (for Inuktitut language).
  542.   There is no script code for Inuit, so it shares the script code
  543.   with Ethiopic.
  544.  
  545. p) Mac OS encodings for script code 29, smCentralEuroRoman.
  546.  
  547. * Central European - This is similar to standard Roman, but with a
  548.   different (and larger) set of European characters and with fewer
  549.   symbols. It is used for Polish, Czech, Slovak, Hungarian, Estonian,
  550.   Latvian, and Lithuanian.
  551.